Add logs and extend metrics for graphql_validation_mode: both
#3674
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@goto-bus-stop, please consider creating a changeset entry in |
|
CI performance tests
|
Geal
requested review from
a team,
garypen,
Geal,
bnjjj and
SimonSapin
and removed request for
garypen
Geal
approved these changes
Sep 1, 2023
BrynCooke
requested changes
Sep 1, 2023
apollo-router/src/error.rs
Outdated
|
|
||
| self.errors.iter().for_each(|err| { | ||
| // Outputs a pretty colourised report on TTYs | ||
| eprintln!("{err}"); |
There was a problem hiding this comment.
We should really gate this entire function to test scope. We should never call println or variants in prod code. Otherwise if this is something that should be used then it should use tracing.
There was a problem hiding this comment.
Schema parse errors do get bubbled up (though they get obscured by #3681)
goto-bus-stop
changed the title
graphql_validation_mode: bothgraphql_validation_mode: both
garypen
pushed a commit
that referenced
this pull request
Sep 12, 2023
This adds logging for query validation errors with either Rust or JS
when there is a mismatch, i.e. one of them validates but the other does
not. In other cases we are not really interested in the specific error
(it will just go back to the user), so we don't need to log there.
To log the Rust validation error well, I now store the ApolloDiagnostics
that were produced on `Query{}`. `Query` is serializable for caching,
but ApolloDiagnostic is not. Here I just skipped serializing
`ApolloDiagnostic` so if `Query` is loaded from cache, it does not have
the validation error stored. I'm not sure this is the right thing to do.
The ApolloDiagnostics are later used after query planning (which may
produce a JS validation error). So it's correct if we can ~safely assume
that we only have valid Query instances cached. Otherwise we might get
spurious error logs from this.
- [ ] So is that a safe assumption? Reading the CachingQueryPlanner
implementation I think it does only store errors (then it's not a
`Query` instance) and fully successful planning (then it has run both
Rust and JS validation already). So it looks fine, but it could be a bit
brittle to rely on this.
I also simplified the validation error printing which
- [x] depends on apollographql/apollo-rs#630.
- [x] and on #3675
<!-- start metadata -->
**Checklist**
Complete the checklist (and note appropriate exceptions) before a final
PR is raised.
- [ ] Changes are compatible[^1]
- [ ] Documentation[^2] completed
- [ ] Performance impact assessed and acceptable
- Tests added and passing[^3]
- [ ] Unit Tests
- [ ] Integration Tests
- [ ] Manual Tests
**Exceptions**
*Note any exceptions here*
**Notes**
[^1]. It may be appropriate to bring upcoming changes to the attention
of other (impacted) groups. Please endeavour to do this before seeking
PR approval. The mechanism for doing this will vary considerably, so use
your judgement as to how and when to do this.
[^2]. Configuration is an important part of many changes. Where
applicable please try to document configuration examples.
[^3]. Tick whichever testing boxes are applicable. If you are adding
Manual Tests:
- please document the manual testing (extensively) in the Exceptions.
- please raise a separate issue to automate the test and label it (or
ask for it to be labeled) as `manual test`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds logging for query validation errors with either Rust or JS when there is a mismatch, i.e. one of them validates but the other does not. In other cases we are not really interested in the specific error (it will just go back to the user), so we don't need to log there.
To log the Rust validation error well, I now store the ApolloDiagnostics that were produced on
Query{}.Queryis serializable for caching, but ApolloDiagnostic is not. Here I just skipped serializingApolloDiagnosticso ifQueryis loaded from cache, it does not have the validation error stored. I'm not sure this is the right thing to do. The ApolloDiagnostics are later used after query planning (which may produce a JS validation error). So it's correct if we can ~safely assume that we only have valid Query instances cached. Otherwise we might get spurious error logs from this.Queryinstance) and fully successful planning (then it has run both Rust and JS validation already). So it looks fine, but it could be a bit brittle to rely on this.I also simplified the validation error printing which
Closes #3681